pgduck client: include conninfo in start-failure error#361
pgduck client: include conninfo in start-failure error#361sfc-gh-dachristensen wants to merge 3 commits into
Conversation
Add an errdetail() clause to the "could not start query engine" ereport() so users can see which connection string was being used when the connection to pgduck_server failed. Issue: #293 Signed-off-by: David Christensen <david.christensen@snowflake.com>
Per review on PR #361: the connection string may include credentials and is an internal detail not appropriate for the client. Emit a separate LOG ereport() with errmsg + errdetail before the user-facing ERROR so administrators can still debug misconfigured servers (issue #293) via the PostgreSQL server log without leaking the conninfo to the client. Signed-off-by: David Christensen <david.christensen@snowflake.com>
Per review on PR #361: the connection string may include credentials and is an internal detail not appropriate for the client. Emit a separate LOG ereport() with errmsg + errdetail before the user-facing ERROR so administrators can still debug misconfigured servers (issue #293) via the PostgreSQL server log without leaking the conninfo to the client. Signed-off-by: David Christensen <david.christensen@snowflake.com>
181666a to
c131d1e
Compare
Per review on PR #361: the connection string may include credentials and is an internal detail not appropriate for the client. Emit a separate LOG ereport() with errmsg + errdetail before the user-facing ERROR so administrators can still debug misconfigured servers (issue #293) via the PostgreSQL server log without leaking the conninfo to the client. Signed-off-by: David Christensen <david.christensen@snowflake.com>
c131d1e to
085dd9b
Compare
| initStringInfo(&buf); | ||
|
|
||
| PGconn *probe = PQconnectStart(PgduckServerConninfo); | ||
|
|
There was a problem hiding this comment.
can we do this when connections are failing?
There was a problem hiding this comment.
Yeah, probably PQconninfoParse() is a better choice here.
There was a problem hiding this comment.
Though that doesn't incorporate defaults; will poke around a little more.
There was a problem hiding this comment.
Looks like a combination of PQconndefaults() and that should work.
Add ResolvePgduckConninfo(), which uses PQconnectStart + PQconninfo to let libpq overlay environment variables (PGHOSTADDR, PGPORT, etc.) and compiled-in defaults onto pg_lake_engine.host, then formats the result as a conninfo string with passwords and debug-only fields stripped. The LOG_SERVER_ONLY errdetail emitted on connection failure now uses this resolved string, so an administrator debugging issue #293-style env-var overrides sees the values libpq actually used rather than just the configured GUC. Signed-off-by: David Christensen <david.christensen@snowflake.com>
0df0208 to
bba35ff
Compare
|
|
||
| if (defaults == NULL) | ||
| { | ||
| /* OOM inside libpq; fall back to the raw configured string */ |
There was a problem hiding this comment.
Probably fairly useless to do this if we're in OOM situation, but YOLO.
sfc-gh-mslot
left a comment
There was a problem hiding this comment.
can you put an example output in the PR description?
|
Hi @sfc-gh-dachristensen — appreciate the context on #361, and agree the diagnostic approach there is the right foundation. I've opened #401 as a companion that stacks directly on top of your branch and addresses the root cause: Together the two changes give:
Happy to squash them into your branch if that's easier, or keep them as separate commits — whatever works best for review. |
PGHOSTADDR overrides host= in the conninfo even when an explicit unix-socket path is set, silently redirecting libpq to connect via TCP instead. Clear it before PQconnectdb so the configured conninfo is always honoured. Stacks on Snowflake-Labs#361, which adds ResolvePgduckConninfo() diagnostic logging for the same issue class. Together the two changes prevent the override and make any remaining connection failures self-diagnosing. Fixes Snowflake-Labs#293.
PGHOSTADDR overrides host= in the conninfo even when an explicit unix-socket path is set, silently redirecting libpq to connect via TCP instead. Clear it before PQconnectdb so the configured conninfo is always honoured. Stacks on Snowflake-Labs#361, which adds ResolvePgduckConninfo() diagnostic logging for the same issue class. Together the two changes prevent the override and make any remaining connection failures self-diagnosing. Fixes Snowflake-Labs#293.
When the connection to pgduck_server fails, the user-facing ERROR only says "could not start query engine", which leaves administrators with nothing to
debug a misconfigured server (e.g. environment variables overriding the configured conninfo).
This PR adds a LOG_SERVER_ONLY ereport before the user-facing ERROR with the connection string in errdetail. The conninfo lands in the PostgreSQL server
log where the administrator can see it, but is never sent to the client (which may be a less-trusted role and the conninfo can include credentials).
The user-facing ERROR is unchanged — the libpq error message is still only included in assertion-enabled builds, and the conninfo is never included.
It may still be worth a follow-up to look at the underlying behavior of environment variables superseding the configured connection string; that seems
undesirable.